Sensible Daten, lokale KI: Warum das präzisere LLM nicht immer die beste Wahl ist

Wer mögliche Cyberangriffe auf eine Maschine oder Komponente bewerten will, muss viele Informationen zusammenführen: Welche Schnittstellen gibt es? Welche bekannten Schwachstellen sind relevant? Welche Bedrohungen ergeben sich daraus und wie lassen sie sich absichern?

Bislang ist dafür viel Handarbeit von Security-Fachleuten nötig. Im it’s OWL Projekt SUSI entwickeln die TH OWL mit ihrem Institut für industrielle Informationstechnik (inIT), Comma Soft, Weidmüller und rt-solutions deshalb ein Softwaretool, das Teile dieser Arbeit mit Sprachmodellen unterstützt. Die Fachleute bleiben für die Bewertung verantwortlich, sollen aber weniger Zeit mit wiederkehrenden Analyseschritten verbringen.

Wie viel KI braucht eine Bedrohungsanalyse?

Wo ein Sprachmodell sinnvoll unterstützen kann, hat das SUSI-Team bereits in einem Leitfaden für den Einsatz von LLMs bei Bedrohungsanalysen beschrieben. Ein möglicher Einsatz: Die KI liest Produktbeschreibungen aus und erfasst daraus etwa Gerätetyp, Schnittstellen und Datenflüsse. Anschließend kann sie diese Informationen mit bekannten Bedrohungen abgleichen und mögliche Gegenmaßnahmen vorschlagen.

Doch spätestens bei der technischen Umsetzung stellt sich eine weitere Frage: Welches Sprachmodell übernimmt diese Aufgabe?

Im bisherigen SUSI-Tool kommt ein spezialisiertes Modell des Projektpartners Comma Soft zum Einsatz, das in einer Cloud in Deutschland betrieben wird. Für viele Anwendungen ist das eine praktikable Lösung. Bei besonders sensiblen Produkt- oder Anlagendaten kann es für Unternehmen aber wichtig sein, dass die Informationen die eigene Infrastruktur gar nicht erst verlassen. Auch die Kosten eines Cloud-Dienstes können gegen eine externe Lösung sprechen.

Dann kommen Modelle ins Spiel, die sich auf eigener Hardware betreiben lassen.

Zwei lokale Modelle im Praxistest

Das Projektteam hat deshalb zwei frei verfügbare Open-Weight-Modelle getestet: gpt-oss:20b von OpenAI und Mistral-Small:24b von Mistral AI. Open Weight bedeutet vereinfacht, dass die Modellgewichte verfügbar sind und die Modelle deshalb auf eigener Hardware betrieben werden können.

Die Tests liefen über Ollama auf einem Server des inIT mit einer NVIDIA Quadro P6000. Die Grafikkarte gehört nicht zur neuesten Generation. Das Team untersucht damit nicht nur, ob lokale Modelle grundsätzlich funktionieren, sondern auch, was mit einer vergleichsweise überschaubaren technischen Ausstattung möglich ist.

Verglichen wurden die Ergebnisse mit dem bisher eingesetzten Cloud-Modell von Comma Soft.

Dabei zählt bei einer Security-Analyse nicht nur, ob ein Sprachmodell viele richtige Treffer liefert. Eine erkannte Bedrohung sollte tatsächlich zum betrachteten System passen. Gleichzeitig darf das Modell relevante Risiken möglichst nicht übersehen. Und wenn dieselbe Analyse wiederholt wird, sollten die Ergebnisse nicht jedes Mal grundlegend anders aussehen.

„Bei einer Bedrohungsanalyse reicht es nicht, nur auf möglichst viele richtige Treffer zu schauen. Wir müssen auch wissen, ob relevante Risiken übersehen werden und ob ein Modell bei derselben Aufgabe zu nachvollziehbaren Ergebnissen kommt“, sagt Simon Jonas Leister, Projektleiter von der Technischen Hochschule Ostwestfalen-Lippe.

Präziser oder verlässlicher? Beides zusammen gelingt noch nicht

Genau hier zeigen die Tests Unterschiede.

gpt-oss:20b lieferte bei den untersuchten Aufgaben die präziseren Antworten. Wiederholte das Team dieselbe Analyse, konnten die Ergebnisse allerdings deutlich voneinander abweichen.

Bei Mistral-Small:24b zeigte sich das umgekehrte Bild. Das Modell kam bei wiederholten Durchläufen weitgehend zu denselben Ergebnissen. Seine Antworten blieben dafür häufiger unscharf und erreichten nicht die Präzision von gpt-oss.

Einen klaren Sieger gibt es damit nicht. Für eine Anwendung wie SUSI muss das Projektteam abwägen, was schwerer wiegt: möglichst genaue einzelne Ergebnisse oder eine hohe Reproduzierbarkeit.

Das klingt nach einem technischen Detail, hat aber unmittelbare Folgen für die Praxis. Wenn eine Security-Risikobeurteilung später nachvollziehbar sein soll, kann es problematisch werden, wenn sich Ergebnisse bei identischen Ausgangsdaten stark verändern. Noch kritischer wäre es allerdings, wenn ein Modell eine tatsächlich relevante Bedrohung gar nicht erkennt.

Die Qualität beginnt vor dem Sprachmodell

Während der Tests wurde noch etwas anderes deutlich: Nicht nur das Modell entscheidet über die Qualität der Analyse.

Ausführliche Produktbeschreibungen führten zu deutlich besseren Ergebnissen. Enthielt ein Dokument beispielsweise genaue Angaben zu Schnittstellen einer Komponente und zu ihrem Einsatz, konnte das Sprachmodell mögliche Bedrohungen präziser zuordnen. Bei oberflächlichen Beschreibungen fehlte dagegen wichtiger Kontext.

Damit rückt eine Frage in den Vordergrund, die bei der Diskussion über immer leistungsfähigere KI-Modelle schnell untergeht: Wie gut sind eigentlich die Informationen, mit denen die KI arbeiten soll?

Für Unternehmen bedeutet das, dass sich die Auswahl eines Sprachmodells nicht von der eigenen Datenbasis trennen lässt. Ein leistungsfähiges Modell kann fehlende oder ungenaue Produktinformationen nicht beliebig ausgleichen.

Warum die Bestenliste im Internet nicht reicht

Auch öffentlich verfügbare Benchmarks halfen dem SUSI-Team nur begrenzt weiter. Sie vergleichen Sprachmodelle anhand standardisierter Aufgaben und liefern damit einen ersten Eindruck ihrer Leistungsfähigkeit. Ob ein Modell aber Bedrohungen für eine industrielle Komponente zuverlässig erkennt, lässt sich daraus nicht ablesen.

Die SUSI-Tests machen deshalb einen grundsätzlichen Punkt sichtbar: Wer ein Sprachmodell für eine spezialisierte Aufgabe in der Industrie einsetzen will, kommt um eigene Tests kaum herum.

Dabei muss es nicht automatisch das größte Modell oder die aufwendigste Cloud-Lösung sein. Lokal betriebene Modelle können gerade dort interessant werden, wo Datenhoheit, Kosten oder vorhandene IT-Infrastruktur eine wichtige Rolle spielen. Ob ihre Leistung ausreicht, entscheidet sich allerdings erst am konkreten Anwendungsfall.

Für das Projektteam ergibt sich daraus bereits die nächste Frage: Wie lassen sich solche Tests künftig einfacher und vergleichbarer machen? Ein einheitliches Verfahren für industrielle Anwendungen könnte Unternehmen helfen, unterschiedliche Sprachmodelle zu prüfen, ohne jedes Mal eine eigene Testmethodik von Grund auf entwickeln zu müssen.