Modellauswahl für Fachbereichsleitungen: Praxisleitfaden
Praxis-Hinweis von Consulting Entenmann: Die fachliche Auswahl eines KI-Modells wird belastbar, wenn Aufgabe, zugelassene Daten, Abnahmekriterien und Fehlerfolgen vor dem Test dokumentiert sind. Die technische, datenschutzbezogene und rechtliche Prüfung bleibt bei den jeweils zuständigen Rollen.
Autor: Niklas Entenmann
Ein lokales oder offen verfügbares KI-Modell auszuwählen, beginnt nicht mit einer Rangliste. Für Fachbereichsleitungen ist die bessere erste Frage: Welche Aufgabe soll zuverlässig unterstützt werden – und woran erkennen wir, dass der Test für diesen Zweck genügt? Wer diese Frage früh beantwortet, trennt nachvollziehbar zwischen technischer Möglichkeit, fachlichem Nutzen und offenen Risiken. Das schützt vor einem Pilot, der zwar beeindruckende Antworten erzeugt, aber im Arbeitsprozess keine belastbare Entscheidung ermöglicht.
Dieser Praxisleitfaden zur Modellauswahl für Fachbereichsleitungen liefert dafür eine Entscheidungslogik. Er ersetzt weder Datenschutz-, Sicherheits- noch Rechtsprüfung. Er hilft jedoch dabei, die fachliche Perspektive so zu dokumentieren, dass IT, Informationssicherheit und weitere zuständige Stellen auf einer klaren Grundlage entscheiden können.
Modellauswahl für Fachbereichsleitungen: Aufgabe vor Modellnamen
Eine Modellauswahl ist dann belastbar, wenn ein konkreter Anwendungsfall, zugelassene Testdaten, Qualitätskriterien und Verantwortlichkeiten vorliegen. Das Modell ist ein Bestandteil dieser Entscheidung, nicht ihr Ausgangspunkt. Ein System, das Texte gut zusammenfasst, kann für die Extraktion aus Formularen ungeeignet sein. Ein Modell mit langem Kontext kann trotzdem unpassende Antworten liefern, wenn die Aufgabenbeschreibung unklar ist oder die Testfälle nicht repräsentativ sind.
Fachbereichsleitungen sollten deshalb zunächst festhalten, welche Nutzergruppe arbeitet, welche Eingaben verarbeitet werden, welches Ergebnis erwartet wird und wann ein Mensch eingreifen muss. Danach lässt sich prüfen, ob ein Cloud-Angebot, ein lokaler Betrieb, eine On-Premises-Variante oder ein hybrider Ansatz zum Prozess passt. Die technische Umsetzung einer lokalen Installation erläutert der Beitrag Lokale KI installieren; hier geht es um die fachliche Entscheidung davor.
1. Den Entscheidungskontext in einem Satz beschreiben
Ein brauchbarer Startsatz lautet beispielsweise: „Das Modell soll freigegebene Serviceanfragen in deutscher Sprache nach festgelegten Kategorien vorsortieren; Mitarbeitende prüfen jede Zuordnung vor der Weiterverarbeitung.“ Dieser Satz macht Aufgabe, Datenrahmen und menschliche Kontrolle sichtbar. „Wir wollen ein leistungsstarkes lokales Modell“ tut das nicht.
Diese Fragen gehören in die fachliche Vorprüfung
- Welche wiederkehrende Aufgabe soll unterstützt werden: Zusammenfassen, Entwurf, Recherche im freigegebenen Bestand, Klassifikation oder etwas anderes?
- Welche Fehler wären folgenreich, und welche können durch eine menschliche Prüfung abgefangen werden?
- Welche Sprache, Fachbegriffe und Dokumentformate kommen tatsächlich vor?
- Welche Daten sind für einen Test zugelassen, und welche bleiben ausdrücklich außerhalb des Versuchs?
- Wie viele Personen nutzen das System gleichzeitig, und welche Antwortzeit ist im jeweiligen Prozess sinnvoll?
Diese Angaben sind keine Formalität. Sie verhindern, dass eine technische Demo mit einem späteren Produktiveinsatz verwechselt wird. Gerade bei unvollständigen, mehrdeutigen oder vertraulichen Inhalten sollte die Fachseite Fehlerbilder dokumentieren: fehlende Quellen, falsche Zuordnung, erfundene Details, unzulässige Datenweitergabe oder Antworten außerhalb der vorgesehenen Aufgabe.
2. Betriebsoptionen getrennt bewerten: Cloud, lokal, On-Premises und hybrid
Die Begriffe werden oft vermischt. „Lokal“ kann einen einzelnen Rechner meinen, während „On-Premises“ üblicherweise den Betrieb auf Infrastruktur der Organisation oder in deren kontrollierter Umgebung beschreibt. Ein hybrider Ablauf kann Daten vorbereiten, Modelle an verschiedenen Orten nutzen oder nur bestimmte Schritte auslagern. Keine dieser Varianten ist automatisch sicher, datenschutzkonform, kostengünstig oder unabhängig.
Die entscheidende Frage lautet: Wo fließen Daten, wer administriert den Dienst, welche Schnittstellen bestehen, wie werden Updates gehandhabt und wer darf Ergebnisse weiterverwenden? Für einen kleinen Pilot kann ein begrenzter lokaler Test sinnvoll sein. Für Lastspitzen, aktuelle Modellfähigkeiten oder geringe eigene Betriebsreife kann ein anderer Ansatz besser passen. Die Übersicht LLMs und Whisper lokal auf eigener Hardware bietet dazu technischen Kontext, ersetzt aber nicht die Entscheidung für den eigenen Prozess.
3. Model Card und Lizenz als prüfbare Entscheidungsunterlagen nutzen
Open-Weight bedeutet nicht, dass jedes Nutzungsszenario erlaubt oder geeignet ist. Vor einer Vorauswahl sollten Verantwortliche die Model Card, die Lizenz und die technische Dokumentation gemeinsam betrachten. Die Hugging-Face-Dokumentation zu Model Cards beschreibt sie als Ort für vorgesehene Nutzung, Grenzen, Trainingsinformationen, Datensätze und Evaluation. Nicht jede Karte ist gleich vollständig. Gerade deshalb ist eine Lücke selbst ein Ergebnis der Prüfung und kein Detail, das stillschweigend übergangen werden sollte.
Für die Lizenz gilt dasselbe: Sie muss konkret geprüft werden. Die Dokumentation zu Repository-Lizenzen weist darauf hin, dass Lizenzen respektiert werden müssen. Der Begriff Open-Weight erlaubt keinen Schluss auf kostenlose, uneingeschränkte oder unveränderte Nutzung. Halten Sie fest, welche Version geprüft wurde, wo die Lizenz auffindbar ist und welche offenen Fragen vor einem produktiven Einsatz geklärt werden müssen.
Checkliste für die Modellunterlagen
- Vorgesehene Nutzung und ausdrücklich genannte Grenzen
- Version, Änderungsstand und Quelle des Modellartefakts
- Dokumentierte Evaluationen, Sprachen und bekannte Schwächen
- Lizenztext sowie interne Zuständigkeit für dessen Prüfung
- Parametergröße, Quantisierung, Fähigkeiten und Kontextangaben der tatsächlich verwendeten Runtime
Bei Ollama können Modelldetails unter anderem Parametergröße, Quantisierung, Fähigkeiten, Kontextlänge und Lizenz ausweisen; die API-Referenz zu Modelldetails dokumentiert diese Angaben. Sie sind nützlich für den Test, dürfen aber nicht als Versprechen für andere Laufzeiten oder Hardware gelesen werden.
4. Hardware und Kontext mit dem echten Testfall prüfen
Hardwarefragen sind relevant, aber ohne Modell, Runtime und Arbeitslast nur bedingt aussagekräftig. Kontextlänge, Speicherbedarf und Antwortverhalten hängen zusammen. Ollama weist in seiner Dokumentation zur Kontextlänge darauf hin, dass größere Kontexte mehr Speicher benötigen und Standardwerte vom verfügbaren VRAM abhängen können. Daraus folgt keine allgemeine Hardwareformel, aber ein klarer Testauftrag.
Statt theoretische Maximalwerte zu vergleichen, sollte der Pilot mit repräsentativen, freigegebenen Fällen arbeiten: kurze und lange Eingaben, typische Fachbegriffe, unvollständige Informationen und bewusst schwierige Beispiele. Pro Fall werden Ergebnisqualität, benötigte Ressourcen, Antwortzeit und Fehlerbild notiert. Bei paralleler Nutzung wird zusätzlich geprüft, ob die Wartezeit für den Arbeitsprozess noch akzeptabel ist. Ein längerer Kontext oder ein größeres Modell ist nicht automatisch besser; maßgeblich sind Aufgabenqualität und Fehlerkosten.
5. Sicherheit und Betrieb als eigenen Entscheidungspunkt behandeln
Ein lokaler Betrieb nimmt Sicherheitsfragen nicht ab. Modellquelle, Aktualisierungen, Rollen und Zugriffsrechte, Protokollierung, Schnittstellen, Datenflüsse und der Umgang mit Prompt-Injection brauchen einen definierten Rahmen. Das BSI zu generativen KI-Modellen benennt neben Chancen auch neuartige und verstärkte IT-Sicherheitsrisiken und empfiehlt eine systematische Risikoanalyse. Für die Modellauswahl bedeutet das: Risiken werden sichtbar gemacht und zuständigen Stellen zugeordnet; sie werden nicht durch den Betriebsort wegdefiniert.
Praktisch hilfreich ist ein kurzer Betriebssteckbrief. Darin stehen Modellquelle und Prüfsumme, verantwortliche Rollen, zugelassene Daten, Berechtigungen, Updateverfahren, Protokollierungsentscheidung, Eskalationsweg und ein Reviewdatum. Eine Fachbereichsleitung koordiniert die fachliche Entscheidung, sollte technische, datenschutzbezogene und rechtliche Freigaben aber nicht pauschal an sich ziehen.
6. Mit einer Entscheidungsmatrix und einem Pilotplan abschließen
| Kriterium | Leitfrage | Nachweis im Pilot |
|---|---|---|
| Aufgabe | Welches Ergebnis wird benötigt? | Beispielaufgaben mit Abnahmekriterium |
| Daten | Welche Testdaten sind freigegeben? | Dokumentierter Datenrahmen |
| Qualität | Welche Fehler sind nicht akzeptabel? | Bewertung durch fachlich zuständige Personen |
| Kontext und Ressourcen | Passt die Runtime zum Testfall? | Messprotokoll für Antwortzeit und Ressourcenbedarf |
| Lizenz und Dokumentation | Ist die Nutzung ausreichend geklärt? | Model Card, Lizenz und offene Punkte |
| Betrieb | Wer aktualisiert, überwacht und eskaliert? | Verantwortungs- und Reviewplan |
| Exit-Option | Was geschieht bei unzureichender Eignung? | Abbruch- oder Wechselkriterium |
Ein minimaler Pilot braucht keine Modellrangliste. Er braucht repräsentative, freigegebene Testfälle, vorher festgelegte Abnahmekriterien, eine dokumentierte Bewertung und ein Datum für die erneute Entscheidung. Vergleichen Sie nicht nur die gefühlte Antwortqualität, sondern auch Fehlerbilder, Nutzbarkeit im Arbeitsablauf und die Voraussetzungen für einen sicheren Betrieb. So lässt sich nachvollziehbar begründen, warum ein Modell für einen begrenzten Use Case weiter geprüft, verworfen oder anders betrieben werden sollte.
Nächster Schritt: Auswahl in einen umsetzbaren Prozess überführen
Wenn Aufgabe, Datenrahmen, Testplan und offene Betriebsfragen auf dem Tisch liegen, wird aus einer Modellfrage ein umsetzbarer KI-Use-Case. Für die gemeinsame Strukturierung von Prozess, Pilot und Verantwortlichkeiten bietet KI-Automatisierung für Unternehmen einen passenden Einstieg. Der Beitrag selbst bleibt bewusst eine Entscheidungshilfe: Er verspricht keine allgemeingültige Modellwahl und ersetzt keine Prüfung im konkreten Einsatzkontext.
2 Kommentare