Glossar

KI‑Agenten sind Systeme, die mit Sprachmodellen selbstständig mehrstufige Aufgaben ausführen: Sie planen, rufen Werkzeuge und Schnittstellen auf, schreiben Dateien oder lösen Transaktionen aus. Damit wächst die Angriffsfläche deutlich, denn manipulierte Eingaben können jetzt echte Handlungen auslösen.

Der Katalog behandelt Agenten‑Risiken als eigene Bedrohungsgruppe: von Werkzeug‑Missbrauch über Rechteausweitung bis zu Kaskadenfehlern zwischen Agenten. Zentrale Kontrollen sind eng begrenzte Berechtigungen, Freigabeschritte für kritische Aktionen und eine lückenlose Protokollierung.

Eine AIBOM ist die Stückliste eines KI‑Systems. Sie erweitert die klassische Software‑Stückliste (SBOM) um die Bestandteile, die bei KI hinzukommen: verwendete Modelle und ihre Version, Trainings- und Feinabstimmungsdaten, Einbettungs- und Vektorbestände, Prompt‑Vorlagen sowie die zur Laufzeit angebundenen Dienste.

Der Nutzen zeigt sich im Ernstfall. Wird eine Schwachstelle in einem Modell oder einem Datensatz bekannt, beantwortet die AIBOM die Frage, welche eigenen Systeme betroffen sind. Sie ist außerdem die Grundlage für Herkunftsnachweise gegenüber Kunden und Aufsicht.

Anbieter und Betreiber sind zwei wichtige Rollen der KI‑Verordnung; daneben gibt es etwa Einführer und Händler. Anbieter entwickeln ein System oder lassen es entwickeln und bringen es unter eigenem Namen in Verkehr oder nehmen es in Betrieb. Betreiber verwenden es in eigener Verantwortung, ausgenommen die persönliche, nicht berufliche Nutzung.

Die Zuordnung ist je System und Tätigkeit zu prüfen. Bei bestimmten Änderungen oder einer Bereitstellung unter eigenem Namen können nach Art. 25 Anbieterpflichten übergehen. Nicht jede Konfigurationsänderung löst dies aus; Bedingungen und Auswirkungen gehören in die konkrete Prüfung.

Quellen zur Einordnung: EU AI Act · Art. 3 / 25

Bei der Pseudonymisierung lassen sich Daten ohne getrennt aufbewahrte Zusatzinformationen nicht mehr unmittelbar einer Person zuordnen. Anonymisierung setzt dagegen voraus, dass Personen unter Berücksichtigung vernünftigerweise nutzbarer Mittel nicht mehr identifizierbar sind.

Das Entfernen von Namen allein reicht nicht aus: Kombinationen aus Text, Ort oder Ereignissen können Personen erkennbar machen. Bewerten Sie den verbleibenden Personenbezug im jeweiligen Kontext, auch bei Embeddings und Modellantworten.

Quellen zur Einordnung: DSGVO / GDPR

Der Autonomiegrad beschreibt, wie weit ein KI‑System ohne menschliches Zutun Entscheidungen trifft und Handlungen ausführt. Er hängt sowohl von den Fähigkeiten des Systems als auch von seiner Konfiguration, seinen Berechtigungen und den vorgesehenen Freigaben ab.

Mehr Handlungsfreiheit kann die Folgen einer Fehlentscheidung vergrößern und Eingriffsmöglichkeiten verringern. Entscheidend sind aber auch Aufgabe, zugängliche Ressourcen und technische Grenzen. Prüfen Sie deshalb tatsächliche Rechte und Kontrollpunkte statt nur die Bezeichnung „autonom“.

Quellen zur Einordnung: NIST AI RMF Core

Ein Anwendungsfall ist eine konkrete Aufgabe, etwa Dokumente prüfen oder Bewerbungen vorsortieren. Eine Bauform beschreibt, wie ein System sie löst: etwa mit Vorhersagemodell, Dokumentenabruf oder einem Agenten mit Werkzeugen. In einem Anwendungsfall können mehrere Bauformen zusammenkommen.

Das grafische Modell dieser Wissensbasis zeigt einen typischen Aufbau. Vergleichen Sie ihn mit Ihrem tatsächlichen System und halten Sie Abweichungen fest; die Bauform allein legt keine gesetzliche Risikoklasse fest.

Quellen zur Einordnung: NIST AI RMF Core

Beim Data Poisoning manipulieren Angreifer Trainings-, Feinabstimmungs- oder Referenzdaten, damit ein Modell gezielt falsche, verzerrte oder schädliche Ausgaben liefert, oft erst ausgelöst durch bestimmte Eingaben. Betroffen sind auch nachgelagerte Datenquellen wie Vektor‑Datenbanken für Retrieval‑Verfahren.

Gegenmaßnahmen setzen an der Datenherkunft an: signierte und versionierte Datensätze, Herkunftsnachweise, Ausreißer‑Analysen vor dem Training und Regressionstests nach jedem Datenupdate. Die Bewertung gehört in die Lieferketten‑Betrachtung des KI‑Systems.

Die Schwellenwertanalyse ist die Vorprüfung zur Datenschutz‑Folgenabschätzung nach Art. 35 DSGVO: Sie klärt strukturiert, ob eine Verarbeitung voraussichtlich ein hohes Risiko für Betroffene birgt und damit eine vollständige DSFA erfordert. Kriterien sind unter anderem neue Technologien, umfangreiches Profiling und besondere Datenkategorien.

Bei generativer KI kommen eigene Fragen hinzu: Prompt‑Übermittlungen an Dritte, Zweckbindung von Trainings- und Kontextdaten sowie die Nachvollziehbarkeit automatisierter Ausgaben. Ein dokumentierter Prüfpfad macht die Entscheidung gegenüber Aufsichtsbehörden belastbar.

Ein Embedding‑Modell wandelt etwa einen Textabschnitt in einen Zahlenvektor um. So lassen sich in einer RAG‑Anwendung passende Dokumentabschnitte zu einer Frage finden. Die Ähnlichkeit der Vektoren ist dabei weder ein Wahrheitsbeweis noch eine Zugriffsberechtigung.

Einbettungen können Informationen über ihre Ausgangsdaten enthalten. Behandeln Sie sie deshalb nicht automatisch als anonym und beziehen Sie Speicherung, Zugriff und Löschung in die Datenprüfung ein.

Quellen zur Einordnung: OWASP LLM08:2025

Die bekannten Risikostufen erleichtern den Einstieg, sind aber keine vier vollständig getrennten gesetzlichen Klassen. Die KI‑Verordnung unterscheidet unter anderem verbotene Praktiken (Art. 5), Hochrisiko‑Systeme (Art. 6 und Anhänge I/III) und besondere Transparenzpflichten (Art. 50). Transparenzpflichten können zusätzlich zu anderen Anforderungen gelten.

Prüfen Sie Zweckbestimmung, konkrete Bedingungen, Ausnahmen und gesetzliche Rolle zusammen. Ein Schnellprüfer gibt eine erste Orientierung; dokumentieren Sie offene Fragen und begründen Sie die anschließende Einordnung am tatsächlichen System.

Quellen zur Einordnung: EU AI Act

Bei der Feinabstimmung wird ein bestehendes Modell mit zusätzlichen Beispielen weitertrainiert, um etwa Stil, Fachsprache oder Aufgabenverhalten anzupassen. Dabei verändern sich Modellparameter. Bei RAG werden dagegen passende Inhalte zur Laufzeit abgerufen und als Kontext mitgegeben.

Trainingsdaten können vom Modell teilweise gespeichert und später offengelegt werden. Das Entfernen eines Beispiels aus dem Datensatz belegt nicht, dass sein Einfluss aus dem Modell entfernt wurde. Prüfen Sie Rechtsgrundlage, Zweckbindung und Betroffenenrechte. Auch RAG benötigt passende Datenschutz- und Zugriffskontrollen.

Quellen zur Einordnung: NIST AI 600-1

KI‑Modelle mit allgemeinem Verwendungszweck (GPAI) sind Basismodelle, die für viele Aufgaben eingesetzt werden können. Die EU‑KI‑Verordnung regelt sie in einem eigenen Kapitel: Anbieter müssen unter anderem technische Dokumentation, Informationen für nachgelagerte Anbieter und eine Zusammenfassung der Trainingsinhalte bereitstellen (Art. 53).

Besonders leistungsfähige Modelle können als GPAI mit systemischem Risiko eingestuft werden. Dann kommen Pflichten wie Modell‑Evaluierungen, Bewertung und Minderung systemischer Risiken sowie Cybersicherheits- und Infrastrukturschutz hinzu (Art. 55). Für Betreiber zählt vor allem, welche Modellkategorie im eigenen System steckt.

Art. 27 der KI‑Verordnung sieht für bestimmte Betreiber und Einsätze eine Grundrechte‑Folgenabschätzung vor. Sie betrachtet unter anderem betroffene Menschen, mögliche Schäden und Maßnahmen zum Schutz ihrer Rechte.

Sie ist von der Datenschutz‑Folgenabschätzung zu unterscheiden, kann aber auf passende Teile einer DSFA Bezug nehmen. Ob sie erforderlich ist und welche Bedingungen gelten, muss am konkreten Einsatz geprüft werden.

Quellen zur Einordnung: EU AI Act

Sprachmodelle können plausibel klingende, aber falsche Fakten, Quellen, Rechtsvorschriften oder Programmierschnittstellen erzeugen. Das wird als Halluzination oder Konfabulation bezeichnet. Auch ein System mit Dokumentenabruf oder Werkzeugzugriff kann Quellen falsch wiedergeben, unbelegte Schlüsse ziehen oder Informationen erfinden.

Prüfen Sie kritische Aussagen anhand geeigneter Belege und messen Sie Fehler im eigenen Anwendungsfall. Eine Quellenangabe allein bestätigt keine richtige Antwort. Die erforderliche fachliche Prüfung richtet sich auch nach den Folgen einer falschen Ausgabe.

Quellen zur Einordnung: NIST AI 600-1

Human in the Loop bedeutet, dass Menschen an bestimmten Entscheidungs- oder Freigabepunkten beteiligt sind. Human on the Loop beschreibt die Überwachung mit Eingriffsmöglichkeit. Human out of the Loop bezeichnet einen Ablauf ohne menschliche Entscheidung bei jedem einzelnen Schritt; übergreifende Aufsicht kann dennoch bestehen.

Die Bezeichnungen allein belegen keine wirksame Aufsicht. Bei Hochrisiko‑Systemen ist Art. 14 der KI‑Verordnung zu berücksichtigen. Prüfen Sie, ob zuständige Personen Ausgaben angemessen verstehen, genügend Zeit und Befugnisse haben und bei Bedarf eingreifen können.

Quellen zur Einordnung: EU AI Act · Art. 14

Ein Jailbreak versucht, Sicherheitsregeln eines Modells zu umgehen, etwa durch Rollenspiele, kodierte Eingaben oder schrittweises Herantasten. Der Begriff beschreibt das Ziel der Umgehung. Prompt Injection beschreibt die Manipulation von Anweisungen durch Eingaben oder eingeschleuste Inhalte; beide können sich überschneiden.

Bewerten Sie die möglichen Folgen im konkreten Einsatz. Auch reine Textausgaben können erheblichen Schaden verursachen. Angebundene Daten, Werkzeuge und Transaktionen schaffen weitere Wirkungsmöglichkeiten. Testen Sie bekannte Muster und dokumentieren Sie Grenzen der Schutzmaßnahmen.

Quellen zur Einordnung: OWASP LLM01:2025

KI‑Kompetenz umfasst Kenntnisse und Fähigkeiten, die Menschen benötigen, um KI‑Systeme sachkundig einzusetzen und ihre Ergebnisse einzuordnen. Dazu gehören ein Verständnis der Möglichkeiten und Grenzen sowie der Risiken für die betroffenen Personen.

Stimmen Sie Lernangebote auf Vorkenntnisse, Aufgaben und Einsatzkontext ab. Halten Sie Schulungen und praktische Übungen nachvollziehbar fest. Die rechtliche Einordnung zu Art. 4 und die verwendete Dokumentfassung finden Sie im Pflichtenkompass.

Ein KI‑Modell verarbeitet Eingaben und erzeugt daraus beispielsweise Vorhersagen oder Text. Zum eingesetzten KI‑System gehören auch Benutzeroberfläche, Datenquellen, Schnittstellen und die Einbindung in menschliche Abläufe. Dasselbe Modell kann deshalb in unterschiedlichen Systemen andere Wirkungen und Risiken haben.

Beschreiben Sie neben Modell und Version auch, wer das Ergebnis nutzt und welche Handlungen daraus entstehen. Die Bewertung eines Basismodells ersetzt diese Betrachtung der gesamten Anwendung nicht.

Quellen zur Einordnung: NIST AI RMF Core

Die Konformitätsbewertung ist ein geregeltes Verfahren zur Prüfung anwendbarer Anforderungen. Welches Verfahren für ein Hochrisiko‑KI‑System gilt, hängt unter anderem vom System und den einschlägigen Vorschriften ab; nicht jedes Verfahren verlangt eine externe Stelle.

Ein ausgefüllter Schnellprüfer, eine Merkliste oder eine Modellkarte ersetzt das Verfahren nicht. Klären Sie zunächst Rolle, Zweckbestimmung und den anwendbaren Prüfweg im Pflichtenkompass.

Quellen zur Einordnung: EU AI Act

Das Kontextfenster umfasst die für einen Modellaufruf verfügbaren Inhalte, etwa Anweisungen, Gesprächsverlauf und abgerufene Dokumente. Die Größe wird meist in Token angegeben: Verarbeitungseinheiten, die nicht mit Wörtern gleichzusetzen sind.

Lange Gespräche oder Dokumente können gekürzt oder zusammengefasst werden. Prüfen Sie, ob dadurch wichtige Einschränkungen oder Quellen fehlen. Ein großes Kontextfenster garantiert weder vollständige Berücksichtigung noch eine richtige Antwort.

Quellen zur Einordnung: Context windows · Claude Docs

Leitplanken sind die technischen Begrenzungen um ein Modell herum: Filter auf Eingaben und Ausgaben, erlaubte und verbotene Themen, Prüfungen vor Werkzeugaufrufen, Budget- und Schrittgrenzen sowie feste Ausgabeformate. Sie wirken außerhalb des Modells und sind deshalb prüfbar und versionierbar.

Sie ersetzen keine Risikobewertung. Filter lassen sich umgehen, und zu strenge Regeln machen ein System unbrauchbar. Belastbar wird der Ansatz erst, wenn jede Leitplanke einer konkreten Bedrohung zugeordnet ist, ihre Wirkung gemessen wird und das verbleibende Restrisiko dokumentiert ist.

Das Model Context Protocol ist ein offener Standard, über den Anwendungen Werkzeuge und Datenquellen einheitlich anbinden. Ein MCP‑Server stellt Fähigkeiten bereit; der Client in der umgebenden Anwendung vermittelt die Aufrufe. Das Sprachmodell kann einen Werkzeugaufruf vorschlagen, führt das Protokoll aber nicht selbst aus.

Zu prüfen sind Herkunft und Integrität der Server, Authentifizierung, Rechte je Werkzeug und die Kontrolle vor der Ausführung. Auch Werkzeugbeschreibungen und zurückgelieferte Inhalte können manipuliert sein. Kritische Handlungen benötigen passende Freigaben und nachvollziehbare Protokolle.

Quellen zur Einordnung: MCP · Architecture

Least Privilege begrenzt Zugriffe auf benötigte Ressourcen und zulässige Handlungen. Ein Assistent, der Dokumente liest, benötigt beispielsweise nicht automatisch Schreibrechte oder die Erlaubnis, Nachrichten zu versenden.

Trennen Sie Lesen, Schreiben und Ausführen. Beschränken Sie Rechte auch zeitlich, wo dies sinnvoll ist, und prüfen Sie den Entzug. Ein Prompt mit Verhaltensregeln ersetzt die technische Berechtigungsprüfung nicht.

Quellen zur Einordnung: NIST SP 800-53 Rev. 5 · AC-6

Model Theft umfasst den unbefugten Zugriff auf Modellgewichte. Bei der Modell‑Extraktion versuchen Angreifer, das Verhalten eines Modells durch systematische Abfragen nachzubilden. Die Offenlegung von Trainingsdaten oder Systemprompts ist davon zu unterscheiden, auch wenn ein Angriff mehrere Ziele verbinden kann.

Typische Kontrollen sind Zugriffsschutz für Gewichte, Ratenbegrenzungen, die Erkennung auffälliger Abfragemuster und die Härtung der Modell‑Infrastruktur. Prüfen Sie daneben Datenabfluss und Systemprompt‑Offenlegung als eigene Angriffsmöglichkeiten.

Quellen zur Einordnung: MITRE ATLAS · Modellzugriff / Model access

Drift bezeichnet das Auseinanderlaufen von Modell und Wirklichkeit: Eingabedaten verschieben sich gegenüber den Trainingsdaten, Begriffe ändern ihre Bedeutung, Nutzungsmuster wandeln sich. Dadurch kann die Qualität der Ergebnisse abnehmen, auch wenn das System selbst unverändert bleibt.

Drift kann schleichend auftreten und lange unbemerkt bleiben. Regelmäßige Messungen helfen, Veränderungen früh zu erkennen. Halten Sie bei der Freigabe Vergleichswerte fest und legen Sie fest, ab welchen Abweichungen die zuständigen Personen eingreifen sollen. Bei zugekauften Modellen kommt hinzu, dass der Anbieter das Modell im Hintergrund austauschen kann.

Eine Modellkarte beschreibt ein Modell in strukturierter Form: vorgesehener Zweck, ungeeignete Einsatzfelder, Trainingsdaten und ihre Herkunft, Messwerte zur Leistung, bekannte Verzerrungen und Grenzen sowie Angaben zu Version und Pflege.

Für Betreiber ist sie der Einstieg in die eigene Bewertung, nicht deren Ersatz. Sie beschreibt, wofür das Modell vorgesehen ist. Ob es sich für Ihren Anwendungsfall eignet, müssen Sie gesondert prüfen. Fehlt eine Modellkarte, halten Sie dies bei der Prüfung des Anbieters und seiner Unterlagen fest.

Monitoring wertet Signale im Betrieb aus, etwa Fehler, Antwortqualität, ungewöhnliche Zugriffe oder Modelländerungen. Protokollierung zeichnet Ereignisse auf und liefert dafür Daten. Viele Protokolle allein ergeben noch keine wirksame Überwachung.

Legen Sie Schwellen, Zuständigkeiten und Reaktionen fest. Prüfen Sie zugleich, welche sensiblen Inhalte in Protokollen landen und wie Zugriff und Aufbewahrung begrenzt werden.

Quellen zur Einordnung: NIST AI RMF Core

In einem Multi‑Agenten‑System teilen sich mehrere spezialisierte Agenten eine Aufgabe: einer plant, einer recherchiert, einer schreibt, einer prüft. Sie tauschen Zwischenergebnisse aus und rufen sich gegenseitig auf, oft ohne dass ein Mensch die einzelnen Schritte sieht.

Das Risiko verschiebt sich von der einzelnen Ausgabe zur Kette. Ein Fehler oder eine manipulierte Anweisung pflanzt sich fort und wird von nachgelagerten Agenten als gesicherte Vorarbeit behandelt. Kontrollen setzen an den Übergängen an: Prüfpunkte zwischen den Agenten, begrenzte Rechte je Rolle und eine Protokollierung, die den ganzen Ablauf rekonstruierbar macht.

Nicht‑menschliche Identitäten sind technische Identitäten für Dienste, Anwendungen und Agenten. Ein Dienstkonto kann beispielsweise einem KI‑Agenten zugeordnet sein. Schlüssel, Zertifikate oder Token dienen dazu, diese Identität gegenüber anderen Systemen nachzuweisen.

Ein Agent benötigt Berechtigungen, um auf Daten und Werkzeuge zuzugreifen. Legen Sie fest, wer die technische Identität verwaltet, welche Zugriffe zulässig sind und wann die Berechtigungen enden. Dokumentieren Sie auch, wie sich Zugänge sperren lassen. Das erleichtert die Prüfung und die Reaktion auf Sicherheitsvorfälle.

Profiling nach der DSGVO verwendet personenbezogene Daten, um Aspekte einer Person zu bewerten oder vorherzusagen, etwa Arbeitsleistung, Interessen oder Verhalten. Nicht jede statistische Auswertung ist damit automatisch Profiling.

Prüfen Sie getrennt, ob eine Entscheidung ausschließlich automatisiert erfolgt und erhebliche Wirkung hat. Profiling und eine automatisierte Entscheidung nach Art. 22 DSGVO sind unterschiedliche Prüfbegriffe.

Quellen zur Einordnung: DSGVO / GDPR

Prompt Injection bezeichnet Angriffe, bei denen manipulierte Eingaben oder eingeschleuste Inhalte das Verhalten eines Sprachmodells umsteuern sollen. Direkte Angriffe stehen in der Eingabe; indirekte Angriffe etwa in abgerufenen Dokumenten, Webseiten oder E‑Mails. Ziel kann sein, vertrauliche Daten auszuleiten oder unerlaubte Handlungen auszulösen.

Kontrollen kombinieren die Trennung von Anweisungen und nicht vertrauenswürdigen Inhalten, begrenzte Werkzeugrechte, Ein- und Ausgabeprüfungen sowie Angriffstests. Kein einzelner Filter garantiert Schutz. Halten Sie fest, welche Angriffe geprüft wurden und welche Risiken verbleiben.

Quellen zur Einordnung: OWASP LLM01:2025

Provenienz beschreibt die Herkunft eines Inhalts und die Verarbeitungsschritte bis zum aktuellen Stand. Dazu können Quelle, Version, Bearbeitung, verantwortliche Stelle und Zeitpunkt gehören. Eine Quellenangabe ist ein Anfang; sie belegt allein weder Echtheit noch Richtigkeit.

Bei RAG sollten Antwort und verwendete Dokumentabschnitte zusammen nachvollziehbar bleiben. Beim Prüfnachweis müssen sich Test, Systemversion und Ergebnis zuordnen lassen.

Quellen zur Einordnung: W3C PROV Overview

In dieser Wissensbasis sind Prüfkandidaten Bedrohungen, die aufgrund der beschriebenen Systemmerkmale näher betrachtet werden sollten. „Zuerst zu prüfen“, „zu klären“ und „Grundlagen“ ordnen den Einstieg in die Prüfung. Ihre Anzahl sagt nicht, wie gefährlich das konkrete System ist.

Für eine Risikobewertung fehlen noch der tatsächliche Einsatz, vorhandene Maßnahmen und deren Wirksamkeit. Die Analysehinweise im Modell lassen sich ein- und ausblenden; dadurch ändern sich weder Systemmerkmale noch Berechnungsregeln.

Quellen zur Einordnung: NIST AI RMF Core

Ein Prüfnachweis verbindet Fragestellung, Testbedingungen, Systemversion, erwartetes und beobachtetes Ergebnis. Er zeigt, was geprüft wurde und welche Aussage sich daraus ableiten lässt. Ein geplanter Test oder ein Link auf eine Maßnahme ist noch kein Wirksamkeitsnachweis.

Notieren Sie auch Prüfumfang, verantwortliche Person und offene Punkte. Die Merkliste sammelt solche Fragen zur Vorbereitung; sie erteilt weder eine Freigabe noch bestätigt sie erfüllte Pflichten.

Quellen zur Einordnung: NIST AI RMF Core

Quellenberechtigungen legen fest, wer ein Dokument oder einen Datensatz lesen darf. In einer RAG‑Anwendung müssen diese Rechte auch bei Suche, Abruf und Weitergabe an das Modell gelten. Ein allgemein berechtigtes Dienstkonto reicht als Schutz für die einzelnen Nutzenden nicht aus.

Testen Sie erlaubte und verbotene Zugriffe mit verschiedenen Rollen. Berücksichtigen Sie auch gelöschte Freigaben, Zwischenspeicher und gemeinsam genutzte Indizes.

Quellen zur Einordnung: OWASP LLM08:2025

Bei Retrieval Augmented Generation sucht das System passende Ausschnitte in einer Wissensbasis und gibt sie dem Modell als Kontext für die Antwort. Dafür muss das Modell nicht neu trainiert werden. Die Qualität hängt unter anderem von den Quellen, dem Abruf und der Verarbeitung der gefundenen Inhalte ab.

Ein präpariertes Dokument kann Anweisungen enthalten, die das Modell irrtümlich befolgt: eine indirekte Prompt Injection. Trennen Sie Quelleninhalt von vertrauenswürdigen Vorgaben und begrenzen Sie Werkzeugrechte technisch. Der Abruf muss außerdem die Zugriffsrechte der fragenden Person berücksichtigen.

Quellen zur Einordnung: OWASP LLM08:2025

Red Teaming ist der geplante Versuch, das eigene KI‑System zum Fehlverhalten zu bringen: Prompt‑Angriffe, Umgehungen, Datenabfluss über Ausgaben, Missbrauch angebundener Werkzeuge. Geprüft wird die gesamte Anwendung, nicht nur das Modell.

Damit daraus mehr wird als eine Sammlung von Anekdoten, braucht es Wiederholbarkeit: feste Angriffsmuster, dokumentierte Ergebnisse je Version und eine Zuordnung der Befunde zu Bedrohungen und Maßnahmen. Die EU‑KI‑Verordnung verlangt für Modelle mit systemischem Risiko ausdrücklich Evaluierungen einschließlich adversarialer Tests.

Das Restrisiko ist das Risiko, das nach Umsetzung aller beschlossenen Gegenmaßnahmen verbleibt. Es wird je Bedrohung aus Eintrittswahrscheinlichkeit und Schadenshöhe abgeleitet. Die zuständigen Personen entscheiden, ob sie das Risiko akzeptieren, weitere Maßnahmen veranlassen oder auf die betreffende Nutzung verzichten.

Eine belastbare Restrisiko‑Methodik dokumentiert je Entscheidung Begründung, Verantwortliche und Termin. So lässt sich später nachvollziehen, wie mit den einzelnen Risiken umgegangen wurde.

Eine Sandbox beschränkt, auf welche Dateien, Netzwerke und anderen Ressourcen ein Prozess zugreifen kann. Bei KI‑Agenten kann sie die Folgen fehlerhafter oder manipulierter Werkzeugaufrufe begrenzen.

Prüfen Sie die tatsächlich erzwungenen Grenzen, etwa Netzwerkziele, Dateizugriffe und Laufzeitbudgets. Ein Container oder ein Testmodus ist nicht automatisch eine ausreichend isolierte Sandbox.

Quellen zur Einordnung: NIST SP 800-95

Schatten‑KI ist die Nutzung von KI‑Diensten außerhalb der geregelten Beschaffung oder Freigabe, etwa ein privater Chatbot‑Zugang für dienstliche Aufgaben. Ursache kann der Wunsch nach einem schnell verfügbaren Arbeitsmittel sein.

Ohne Übersicht über die Dienste sind Datenwege, Verantwortlichkeiten und vertragliche Schutzmaßnahmen schwer zu prüfen. Klären Sie Zweck, Datenarten und gegebenenfalls notwendige Vereinbarungen. Ein leicht zugängliches freigegebenes Angebot und verständliche Nutzungsregeln können ungeregelte Nutzung verringern.

Quellen zur Einordnung: NIST AI RMF Core

Die Systemgrenze beschreibt den Umfang einer Untersuchung: etwa Chatoberfläche, Modellanbieter, Dokumentensuche, angeschlossene Werkzeuge und menschliche Freigaben. Externe Dienste können innerhalb des betrachteten Ablaufs liegen, obwohl sie von einer anderen Organisation betrieben werden.

Halten Sie auch Übergänge fest: Welche Daten verlassen das System, wer erhält Ergebnisse und wo können Handlungen ausgelöst werden? Begründen Sie ausgeschlossene Teile, damit relevante Abhängigkeiten nicht unsichtbar werden.

Quellen zur Einordnung: NIST AI RMF Core

Der Systemprompt ist die vorangestellte Anweisung, die Rolle, Tonfall, erlaubte Themen und Grenzen eines Modells festlegt. Er ist für die nutzende Person meist unsichtbar, prägt aber jede Antwort und enthält oft Geschäftslogik.

Zwei Punkte sind bewertungsrelevant. Erstens ist er kein Geheimnis: Systemprompts lassen sich häufig erfragen oder erschließen, deshalb gehören Schlüssel und vertrauliche Regeln nicht hinein. Zweitens ist er eine Konfiguration mit Wirkung auf das Ergebnis und sollte versioniert, geprüft und freigegeben werden wie Programmcode.

TOMs sind die Schutzmaßnahmen, mit denen Verantwortliche die Sicherheit einer Verarbeitung gewährleisten (Art. 32 DSGVO): von Verschlüsselung, Zugriffskontrolle und Protokollierung bis zu Schulungen, Rollenkonzepten und Freigabeprozessen. Sie müssen dem Risiko der Verarbeitung angemessen sein.

Bei KI‑Systemen kommen KI‑spezifische Maßnahmen hinzu, etwa Filterketten gegen Prompt‑Angriffe, Kontrollen gegen Datenabfluss über Ausgaben und die Überwachung von Modell- und Datenänderungen. Eine Risikoanalyse ordnet jede Maßnahme einer konkreten Bedrohung zu und macht den Reifegrad messbar.

Eine Vektordatenbank ermöglicht Ähnlichkeitssuchen über Embeddings. Metadaten können beispielsweise Dokumentversion, Herkunft und Zugriffsrechte zuordnen. Retrieval bezeichnet den Abruf; RAG verbindet diesen Abruf anschließend mit der Antworterzeugung.

Prüfen Sie, ob der Abruf nur freigegebene und für die fragende Person erlaubte Inhalte liefert. Ein Treffer ist nicht schon deshalb zuverlässig, weil er weit oben in der Ergebnisliste steht.

Quellen zur Einordnung: OWASP LLM08:2025

Beim Werkzeugaufruf entscheidet das Modell, eine Funktion aufzurufen: eine Suche, eine Datenbankabfrage, einen Versand, eine Buchung. Es liefert dabei die Parameter, ausgeführt wird der Aufruf von der umgebenden Anwendung.

Damit verlässt das System die reine Textwelt. Jede Ausgabe kann eine Handlung auslösen, und die Parameter stammen aus einem Text, der manipuliert sein kann. Zu prüfen sind die Rechte je Werkzeug, die Prüfung der Parameter vor der Ausführung, Freigaben für kritische Aufrufe und die Frage, welche Aufrufe sich rückgängig machen lassen.

Die Zweckbestimmung ist der vom Anbieter vorgesehene Einsatz einschließlich Nutzungskontext und Bedingungen. Die KI‑Verordnung knüpft daran unter anderem die Prüfung möglicher Hochrisiko‑Anforderungen. Ein Produktname allein beschreibt den Zweck nicht ausreichend.

Notieren Sie Aufgabe, Nutzergruppen, betroffene Personen und die Wirkung der Ausgabe. Vergleichen Sie die Unterlagen des Anbieters mit dem tatsächlich geplanten Einsatz; Abweichungen können eine erneute Prüfung erfordern.

Quellen zur Einordnung: EU AI Act