Warum LLM-Evaluation in der Verteidigung anders ist
LLMs werden zunehmend für Recherche, Zusammenfassung, Lagebilder, Dokumentenanalyse, Wissensmanagement und Entscheidungsunterstützung getestet. In verteidigungsnahen Programmen ist ihre Evaluation jedoch deutlich anspruchsvoller als in kommerziellen Produktteams. Die Risiken sind höher, die Daten sensibler und die Fehlertoleranz geringer.
Ein Modell, das in einem öffentlichen Benchmark gut abschneidet, ist deshalb noch lange nicht geeignet für ein europäisches Verteidigungsprogramm. Entscheidend ist nicht nur, ob das Modell allgemein leistungsfähig ist. Entscheidend ist, ob es in der konkreten Einsatzumgebung zuverlässig, nachvollziehbar, robust, datenschutzkonform und kontrollierbar bleibt.
Souveräne LLM-Evaluation bedeutet in diesem Kontext: Evaluation unter europäischer Datenkontrolle, mit klaren Sicherheitsanforderungen, dokumentierten Testsets, kontrollierten Reviewer-Prozessen und kontinuierlicher Messung über Modellversionen hinweg.
Die Anforderung an souveräne Datenresidenz
Viele verteidigungsnahe KI-Programme können Daten nicht in beliebige Cloud- oder API-Umgebungen übertragen. Dokumente, Prompts, Evaluationssets, Modellantworten und menschliche Bewertungen können operative, technische oder strategische Informationen enthalten. Selbst wenn die Daten nicht formell klassifiziert sind, können sie sensibel sein.
Deshalb ist Datenresidenz ein zentrales Auswahlkriterium. Evaluation sollte in kontrollierten Umgebungen stattfinden, idealerweise mit Hosting und Zugriffskontrollen innerhalb Europas, klaren Löschprozessen, Rollenrechten und Audit-Trails. Wenn externe Partner eingebunden werden, müssen Scope, Datenzugriff, Subunternehmer, Reviewer-Standorte und Sicherheitsmaßnahmen explizit geklärt werden.
Souveränität bedeutet nicht zwangsläufig, alles intern zu machen. Sie bedeutet, jederzeit zu wissen, wo Daten liegen, wer Zugriff hat, welche Systeme sie verarbeiten und wie Ergebnisse dokumentiert werden.
Sechs Evaluationskategorien, die Verteidigungsprogramme benötigen
1. Red Teaming gegen Jailbreaks, Prompt Injection und Datenextraktion
LLMs müssen gegen Angriffe getestet werden, die Sicherheitsregeln umgehen, vertrauliche Informationen extrahieren, Tools missbrauchen oder unerwünschte Anweisungen ausführen sollen. Red Teaming ist besonders wichtig, wenn Modelle mit RAG-Systemen, internen Dokumenten oder Agenten-Workflows verbunden sind.
2. Faktizität und Halluzinationsbewertung gegen kuratierte Referenzen
In sicherheitskritischen Anwendungen reicht eine plausible Antwort nicht aus. Das Modell muss nachweisbar korrekte Informationen liefern oder Unsicherheit sauber kommunizieren. Dazu braucht es Goldsets, Referenzdokumente, Quellenprüfung und Rubriken, die zwischen kleinen Ungenauigkeiten und kritischen Falschinformationen unterscheiden.
3. Bias-, Fairness- und Safety-Audits im Einklang mit dem EU AI Act
Verteidigungsprogramme müssen Risiken, Grenzen und Kontrollmechanismen dokumentieren. Evaluation sollte daher nicht nur technische Genauigkeit messen, sondern auch diskriminierende Muster, gefährliche Empfehlungen, übermäßiges Selbstvertrauen, fehlende Ablehnung und ungeeignete Antworten in sensiblen Szenarien prüfen.
4. Mehrsprachige Evaluation über operative europäische Sprachen hinweg
Europäische Teams arbeiten selten nur auf Englisch. Französisch, Deutsch, Spanisch, Italienisch, Niederländisch, Polnisch, Arabisch oder andere Sprachen können je nach Einsatzkontext relevant sein. Ein Modell kann in Englisch stark sein und in anderen Sprachen schlechtere Faktizität, Safety oder Terminologie zeigen.
5. Langfristiges Benchmarking über Modellversionen hinweg
LLM-Leistung verändert sich mit neuen Modellversionen, Prompt-Änderungen, RAG-Indizes, Retrieval-Strategien oder Guardrails. Verteidigungsprogramme brauchen deshalb longitudinales Benchmarking: dieselben oder kontrolliert erweiterten Testsets werden wiederholt eingesetzt, damit Verbesserungen und Regressionen sichtbar werden.
6. End-to-End-RAG-Evaluation für Intelligence- und Dokumentenworkflows
Wenn ein LLM auf interne Dokumente zugreift, muss nicht nur die Antwortqualität bewertet werden. Auch Retrieval, Quellenabdeckung, Zitierqualität, Kontextnutzung, Nichtbeantwortung bei fehlender Evidenz und Umgang mit widersprüchlichen Dokumenten müssen geprüft werden.
Red Teaming für taktische und dual-use LLMs
Red Teaming ist kein einmaliges Prompt-Spiel. Es ist ein strukturierter Test gegen ein definiertes Bedrohungsmodell. Zuerst muss geklärt werden, was das System schützen soll: vertrauliche Dokumente, operative Informationen, Tool-Zugriffe, Modellrichtlinien, Nutzeridentitäten, technische Parameter oder Entscheidungslogik.
Danach werden Angriffskategorien definiert: direkte Jailbreaks, Rollenspiel-Angriffe, indirekte Prompt Injection über Dokumente, Datenexfiltration, schrittweise Umgehung, Social Engineering, falsche Autorität, Übersetzungsangriffe, Mehrsprachigkeit, toxische oder gefährliche Anfragen und Tool-Missbrauch.
Die Evaluatoren müssen ausreichend kompetent sein, um realistische Angriffe zu formulieren, dürfen aber nur auf Daten zugreifen, die ihrem Freigabe- und Sicherheitsprofil entsprechen. Für sensible Programme kann es sinnvoll sein, interne Experten mit externen Evaluationsmethoden zu kombinieren.
Mehrsprachige Evaluation in europäischen Einsatzkontexten
Mehrsprachigkeit wird oft unterschätzt. Ein Modell kann korrekte englische Antworten liefern, aber bei deutscher Fachterminologie, französischen juristischen Formulierungen oder mehrsprachigen Dokumentenketten Fehler machen. Besonders problematisch sind Übersetzungsartefakte: Das Modell scheint eine Frage zu beantworten, verschiebt aber Bedeutung, Schweregrad oder Unsicherheit.
Ein gutes Evaluationsset enthält daher Prompts und Referenzen in den tatsächlichen Arbeitssprachen. Es prüft nicht nur Übersetzung, sondern domänenspezifisches Verständnis, Quellenverwendung, Abkürzungen, lokale Terminologie und konsistente Safety-Regeln über Sprachen hinweg.
EU-AI-Act-Compliance und Dokumentation
Der EU AI Act erhöht den Bedarf an nachvollziehbarer KI-Governance. Auch wenn konkrete Pflichten vom Systemtyp und Einsatzbereich abhängen, sollten verteidigungsnahe Programme frühzeitig dokumentieren, welche Risiken geprüft wurden, welche Daten genutzt wurden, welche Reviewer beteiligt waren, welche Ergebnisse erzielt wurden und welche Grenzen bestehen.
Evaluationsergebnisse sollten nicht als lose Tabellen abgelegt werden. Sie sollten versioniert, reproduzierbar und auditierbar sein: Modellversion, Promptversion, Retrieval-Konfiguration, Datensatzversion, Rubrik, Reviewer-Rolle, Bewertungsdatum, Qualitätsmetriken und Entscheidungen zur Freigabe oder Nachbesserung.
Interne Evaluationsfähigkeit oder externer Partner?
Viele Programme stehen vor der Frage, ob sie LLM-Evaluation vollständig intern aufbauen oder mit einem Partner arbeiten sollten. Interne Teams kennen Domäne, Systeme und Sicherheitsanforderungen. Externe Partner bringen Evaluationsmethodik, Reviewer-Operations, Red-Team-Design, QA-Prozesse und Skalierungserfahrung ein.
In der Praxis funktioniert häufig ein hybrides Modell am besten. Interne Fachexperten definieren Risiko, Use Cases und Akzeptanzkriterien. Ein spezialisierter Partner operationalisiert Testsets, Reviewer-Schulungen, Bewertungsworkflows und Qualitätskontrolle. Sensible Inhalte können dabei in kontrollierten Umgebungen bleiben.
Typische Muster aus europäischen Programmen
Muster 1: Qualifikation vor Deployment
Vor dem produktiven Einsatz wird ein LLM auf kuratierten Szenarien geprüft: Zusammenfassungen, Frage-Antwort-Aufgaben, Quellenverwendung, Ablehnung ungeeigneter Anfragen und Robustheit gegenüber adversarial prompts. Die Ergebnisse bestimmen, ob das System freigegeben, eingeschränkt oder überarbeitet wird.
Muster 2: Kontinuierliche RAG-Evaluation
Bei RAG-Systemen verändert sich die Qualität mit jedem Dokumentenbestand, Index-Update und Retrieval-Parameter. Regelmäßige Evaluation zeigt, ob relevante Quellen gefunden werden, ob Antworten vollständig sind und ob Halluzinationen trotz Retrieval auftreten.
Muster 3: Red Teaming vor souveränem Modellbetrieb
Wenn ein Modell in einer souveränen Umgebung betrieben wird, wird vorab getestet, ob Guardrails, Zugriffskontrollen und Systemprompts realistischen Angriffen standhalten. Dabei werden nicht nur Outputs bewertet, sondern auch Logging, Eskalation und Incident-Response-Prozesse.
Häufige Fehler in Verteidigungs-Evaluationsprogrammen
Fehler 1: Zu kleine Testabdeckung
Ein paar Dutzend Prompts reichen nicht aus, um ein komplexes LLM-System zu qualifizieren. Evaluation braucht Abdeckung über Aufgaben, Sprachen, Dokumenttypen, Risikokategorien und Edge Cases hinweg.
Fehler 2: Einsprachige Evaluation für mehrsprachige Systeme
Wenn das System in mehreren Sprachen genutzt wird, muss auch in diesen Sprachen evaluiert werden. Sonst bleiben wichtige Fehler unsichtbar.
Fehler 3: Schwache Dokumentationsdisziplin
Ohne Versionierung und klare Metadaten ist später nicht nachvollziehbar, warum ein Modell freigegeben wurde oder welche Risiken geprüft wurden.
Fehler 4: Zu enger Evaluatorenpool
Nur technische Reviewer oder nur Domänenexperten reichen selten aus. Gute Evaluation kombiniert Sicherheit, Fachwissen, Sprache, UX und Modellverständnis.
Fehler 5: Kein longitudinales Tracking
Ein Modell kann nach einem Update besser in einem Benchmark und schlechter in einem produktiven Use Case werden. Ohne wiederholbare Tests bleiben Regressionen unbemerkt.
Wie Sie eine souveräne LLM-Evaluationsfähigkeit starten
Starten Sie mit einem klar begrenzten Use Case. Definieren Sie, welche Entscheidungen das Modell unterstützt, welche Daten es sieht, welche Risiken nicht akzeptabel sind und welche Sprachen relevant sind. Erstellen Sie anschließend ein kleines, aber hochwertiges Evaluationsset mit realistischen Prompts, Referenzantworten und Bewertungskriterien.
Führen Sie eine Kalibrierungsrunde mit mehreren Reviewern durch. Messen Sie Konsistenz, diskutieren Sie Grenzfälle und schärfen Sie die Rubrik. Erst danach sollte die Evaluation skaliert werden. Parallel sollten Logging, Datenresidenz, Zugriffskontrollen und Exportformate geklärt werden.
Fazit
Souveräne LLM-Evaluation ist kein optionaler QA-Schritt. Für europäische Verteidigungsprogramme ist sie die Grundlage dafür, Modelle kontrolliert, nachvollziehbar und sicher in reale Workflows zu bringen. DataVLab unterstützt Teams bei LLM-Evaluation, Red Teaming, RAG-Bewertung, mehrsprachigen Reviews und menschlicher Qualitätskontrolle in europäischen Workflows. Kontaktieren Sie uns, wenn Sie ein Evaluationsprogramm aufbauen oder einen Pilot definieren möchten.
