Machine Learning & KI
Eine moderne LLM-Anwendung besteht technisch nicht nur aus einem Modell. System Prompts, Retrieval, Vektorsuche, Wissensquellen, Tool-Aufrufe, Agentenlogik, Moderation, Berechtigungen und externe APIs können das Ergebnis wesentlich beeinflussen. Für eine Begutachtung muss deshalb das gesamte relevante Anwendungssystem als Untersuchungsgegenstand beschrieben werden.
Kurzantwort
Zu erfassen sind mindestens Modell und Version, System- und Entwickleranweisungen, Retrieval-Pipeline, Wissensquellen, Tool-Schnittstellen, Berechtigungen, Laufzeitparameter und relevante Schutzmechanismen. Ein einzelner Prompt-Output ist nur ein Befund für genau diesen Kontext und keine allgemeine Eigenschaft des Modells oder Systems.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Modell und Anwendungssystem unterscheiden
Das Basismodell erzeugt Ausgaben innerhalb einer Anwendung, deren Orchestrierung zusätzlichen Kontext und Aktionen bestimmt. Modellanbieter, API-Version, Gateway, Prompt-Template, Retrieval und Tools können unabhängig voneinander geändert werden.
Deshalb wird dokumentiert, welche Komponenten im streitigen oder geprüften Zustand aktiv waren. Bei SaaS-Modellen können Modellversionen oder serverseitige Änderungen nur soweit erfasst werden, wie der Anbieter sie technisch ausweist.
Ein reproduzierbarer Test benötigt neben dem Prompt auch Systemanweisungen, Parameter, Toolzustand und relevante Datenquellen.
2. System Prompts und Instruktionshierarchie
System- und Entwicklerprompts definieren Anweisungen, die der Nutzer nicht zwingend sieht. Für die Begutachtung ist relevant, welche Fassung tatsächlich verwendet wurde und ob zusätzliche dynamische Instruktionen eingefügt werden.
OWASP beschreibt Prompt Injection als Risiko, bei dem Eingaben das Verhalten eines LLM-Systems unbeabsichtigt verändern können. RAG oder Fine-Tuning beseitigen dieses Risiko nicht automatisch.
Eine Prüfung kann daher untersuchen, wie externe Inhalte in den Kontext gelangen, welche Trenn- und Validierungsmechanismen bestehen und welche Aktionen nach einem Modelloutput möglich sind.
3. Retrieval-Augmented Generation und Wissensquellen
Bei RAG-Systemen beeinflussen Dokumentbestand, Chunking, Embeddings, Suchparameter, Filter und Ranking die bereitgestellten Kontexte. Eine Antwort kann sich deshalb ändern, obwohl Modell und Nutzerprompt identisch bleiben.
Für die Nachvollziehbarkeit werden Wissensbasis, Indexstand, Retrievalparameter und tatsächlich abgerufene Dokumente soweit verfügbar dokumentiert. Eine Quellenanzeige im UI ist nicht automatisch identisch mit dem intern verwendeten Kontext.
Fehler können aus fehlenden Dokumenten, veralteter Wissensbasis, ungeeignetem Retrieval oder der Modellinterpretation des gefundenen Kontexts entstehen. Diese Ursachen sollten getrennt geprüft werden.
4. Tools, Agenten und Berechtigungen
LLM-Systeme können über Tools Dateien lesen, APIs aufrufen, Code ausführen oder Geschäftsprozesse anstoßen. Damit wird die Berechtigungs- und Kontrollarchitektur Teil des Untersuchungsgegenstands.
Besonders wichtig sind Scope und Privilegien der verwendeten Service Accounts, Bestätigungsmechanismen, Eingabevalidierung und die Behandlung von Toolausgaben als potenziell untrusted Input.
OWASP hat seine GenAI-Sicherheitsarbeit inzwischen auf LLM- und agentische Systeme ausgeweitet. Für ein Gutachten dienen solche Risikokataloge als Strukturierungshilfe; der konkrete Befund muss am realen System erhoben werden.
5. Reproduzierbarkeit und Aussagegrenzen
LLM-Ausgaben können stochastisch sein. Reproduzierbarkeit bedeutet daher häufig nicht byteidentische Antworten, sondern dokumentierte Testbedingungen, wiederholte Versuche und messbare Kriterien für relevante Eigenschaften.
Ein einzelner erfolgreicher oder problematischer Prompt belegt keine allgemeine Robustheit oder Unsicherheit des Systems. Testmenge, Varianten, Angriffsmodelle und Detection Limits müssen zur Aussage passen.
NIST AI 600-1 behandelt generative KI als spezifisches Risikoprofil innerhalb des AI RMF. Für die technische Begutachtung folgt daraus vor allem, Risiken über den gesamten Lebenszyklus und Systemkontext zu betrachten, nicht nur das Modell isoliert.
6. Konfigurationsmanifest und reproduzierbare Testmatrix
Für die Begutachtung eines LLM-Systems ist ein Konfigurationsmanifest zweckmäßig. Es erfasst Modellbezeichnung und soweit verfügbar Modellversion, System Prompt, relevante Prompt-Templates, Retrieval-Konfiguration, Embedding- und Indexstand, Tool-Schnittstellen, Berechtigungen, Sicherheitsfilter sowie Decoding-Parameter.
Eine Testmatrix sollte nicht nur einzelne Beispielprompts wiederholen. Sie ordnet Eingabeklassen, erwartete Systempfade, erlaubte Tool-Aktionen, relevante Wissensquellen und beobachtete Ausgaben. Bei stochastischer Ausgabe können mehrere Wiederholungen erforderlich sein, damit einzelne Zufallsergebnisse nicht überbewertet werden.
Besondere Aufmerksamkeit gilt externen Zuständen: ein RAG-Index kann aktualisiert werden, ein Tool liefert veränderliche Daten, ein Provider kann ein Modell hinter derselben Produktbezeichnung austauschen. Solche Änderungen sind Revisionsanlässe und müssen bei späteren Reproduktionen berücksichtigt werden.
Warum ist ein LLM nicht der gesamte Untersuchungsgegenstand?
Moderne GenAI-Anwendungen bestehen aus mehr als dem Basismodell. System Prompts, Retrieval, Vektorsuche, Tools, Berechtigungen und Anwendungscode können das beobachtete Verhalten entscheidend verändern.
NIST AI 600-1 behandelt generative KI als System- und Risikokontext; OWASP beschreibt unter anderem Prompt Injection, Excessive Agency und Schwächen in Vektor- und Embedding-Komponenten als relevante GenAI-Risikofelder.
Für eine Begutachtung wird deshalb die tatsächlich eingesetzte Anwendungskette untersucht und nicht nur der Name des zugrunde liegenden Modells.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind Basismodell, Anbieter und soweit verfügbar konkreter Modellstand dokumentiert?
- Sind System Prompt und relevante Prompt-Templates versionsbezogen gesichert?
- Sind RAG-Quellen, Indexstand, Embeddings und Retrieval-Parameter erfasst?
- Sind Tool-Schnittstellen und ihre tatsächlichen Berechtigungen dokumentiert?
- Sind Decoding-Parameter, Seeds oder Wiederholungsstrategie für Tests festgelegt?
- Werden externe Zustände und Provideränderungen als Revisionsanlass behandelt?
- Ist die Schlussfolgerung auf die getesteten Eingabeklassen und den dokumentierten Systemstand begrenzt?
Konstruiertes Beispiel
Ein Assistent beantwortet eine Frage unterschiedlich, nachdem ein Dokument in der Wissensbasis aktualisiert wurde. Das Modell ist unverändert. Die Untersuchung zeigt, dass der neue Index einen anderen Abschnitt retrieved und dieser Kontext die Antwort beeinflusst. Der Befund betrifft damit die RAG-Pipeline und den Indexstand, nicht allein das Basismodell.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Amtliche technische Leitlinie NIST AI 600-1: Generative Artificial Intelligence Profile als Profil zum AI Risk Management Framework. Quelle öffnen.
- Fachlicher Sicherheitsrahmen OWASP GenAI LLM Top 10 2026 als aktuelle Ausgabe zu zentralen Sicherheitsrisiken von LLM-basierten Anwendungen. Quelle öffnen.
- Eigene Methodik Quellen und Methodik. Quelle öffnen.
- Amtliche technische Leitlinie NIST AI RMF 1.0 als übergreifender freiwilliger Rahmen für das Management von KI-Risiken. Quelle öffnen.
- Technische Sicherheitsreferenz OWASP Top 10 for Agentic Applications 2026 als Referenz für Risiken autonomer und tool-nutzender Agentensysteme. Quelle öffnen.
Weiterführende Beiträge
- ML-Modell als Untersuchungsgegenstand
- Robustheit technisch prüfen
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
- Eigenes Fachbuch Von Daten zu Lösungen in Data Science mit Python – Vom Problem zur verantwortbaren Lösung
- Eigenes Fachbuch Kritisches Denken in Data Science mit Python – Vom Beobachten zur verantwortbaren Entscheidung
- Eigener veröffentlichter Fachbeitrag Verantwortungsvoller KI-Einsatz in der Praxis: Frameworks, Tools und regulatorische Einbettung in 15 Anwendungsfeldern
Technische Untersuchung zum Themenbereich Machine Learning & KI
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Data-Science- und KI-Gutachten